Computer networking capabilities of a home personal computer (PC) are typically provided by telephone companies (Telcos) or commercial Internet Service Providers (ISPs) who operate network access points along the information superhighway. It is through these network access points that the user is able to connect with public domains, such as the Internet, and private domains, such as an intra-company computer network of the user's employer.
In the wholesale Internet access environment, the network access provider (NAP) and the network service provider (NSP) are not necessarily the same entity. Telcos and other wholesale ISPs are typical NAPs, who operate gateways (network access servers, access routers, or the like) in their points of presence (PoPs), and provide local loop access services to PCs. NSPs are typically the customers of NAPs, who are allowed to use the NAP's gateways to provide their Internet Protocol (IP)-based services, such as Internet access, network access, or voice over IP (VoIP) services to the PCs.
FIG. 1 illustrates Layer 2 Tunneling Protocol (L2TP). L2TP tunneling is a common service architecture for Point-to-Point (PPP) clients currently available at NAPs. In the typical L2TP tunneling environment, a PC 100 of a PPP client 105 starts a PPP session by dialing into a L2TP access concentrator (LAC) 110 located at the NAP's point of presence (PoP). The LAC 110 exchanges PPP messages with the client's PC 100 and communicates with a L2TP network server (LNS) 115 of a remote domain 120 such as an ISP or a private company. The LNS 115 is typically a home gateway (HGW) of the remote domain 120. The communication between the LAC 110 and the LNS 115 is by way of L2TP requests and responses. When a L2TP tunnel 125 is set up, the LAC 110 forwards the PPP session over the L2TP tunnel 125 to the LNS 115. Data packets in the PPP session are encapsulated into L2TP frames that are destined for the IP address of the LNS 115.
The LNS 115 is a termination point of the L2TP tunnel 125. The LNS 115 accepts L2TP frames, strips the L2TP encapsulation, and processes the incoming PPP frames for the appropriate interface. The PPP frames are processed and passed to higher layer protocols, i.e., the PPP session is terminated at the LNS 115. The PPP session termination requires and includes user authentication via a Remote Authentication Dial-In User Service (RADIUS) or other means. An authenticated PPP client then receives an IP address, a Domain Name System (DNS) address, and IP-based services that the client contracted. These are forwarded back to the client over the L2TP tunnel 125 through the LAC 110.
The L2TP passes protocol-level (or Data Link-level) packets through the virtual tunnel between the endpoints of a point-to-point connection, i.e., the client's PC 100 and the LNS 115. The L2TP is suitable for virtual private networking (VPN), in which users can dial into a NAP's network access server and join a private (typically corporate) network that is remote from the NAP's PoP.
FIG. 2 is a block diagram that illustrates a L2TP service architecture in which the NAP and NSP are different entities. Users 200–215 represent authorized users of a network at remote domain 220. NAP 225 provides network access to user A 200 and user B 205 and tunnels the PPP sessions via tunnel 230 to LAC 250. NAP 240 provides network access to user C 210 and user D 215 and tunnels the PPP sessions via tunnel 245 to LAC 250. NSP 235 may also provide services for other remote domains (not shown in FIG. 2). LAC 250 aggregates tunnels 245 and 230 into a single tunnel 255 to the LNS 275 at remote domain 220.
A typical service level agreement (SLA) specifies a minimum bandwidth to be provided during specified times of the day or week together with pricing information for the provision of such services. As shown in FIG. 2, NAP 225 and NAP 240 have separate SLAs 260, 265 with NSP 235. Additionally, NSP 235 has a third SLA 270 with the remote domain 220. However, since sessions going to the remote domain 220 use the same tunnel, they are accorded the same level of service for that interface.
This approach has a number of drawbacks. First, placing all L2TP sessions for a particular remote domain on single tunnel increases the risk that all sessions will be dropped if the tunnel drops. This in turn increases the risk of violating a SLA. Second, placing all L2TP sessions for a particular remote domain on a single tunnel accords the same level of service to all sessions, regardless of any SLAs. Third, concentrating sessions over a single interface typically results in relatively inefficient resource utilization.
What is needed is a solution that minimizes the risk of putting all tunneled sessions to a remote domain on a single tunnel. A further need exists for such a solution that enables differentiated service for each tunneled session. Yet another need exists for such a solution that provides relatively efficient utilization of resources.